1. Technical Field
The invention relates to printing data that are stored in an electronic format. More particularly, the invention relates to a method and apparatus for printing variable data.
2. Description of the Prior Art
A personalized print job is a description of a document composed of a number of copies, where each copy can be uniquely customized for the intended recipient. The pages are composed of text, graphics, and images which can be unique to just that copy, identical on every copy, or used on some copies of the document but not on others. For example, in a customized product brochure, unique elements can include the recipient's name and address, while the product company name and logo are identical on every copy, and the picture of the specific product that the recipient is interested in is found on some copies of the document, but not on others.
A personalization system includes every component that is required to build and print a personalized job. The front end of the system is the job creation process, which is generally driven by a database and authoring applications which build the description of a personalized job. The system also includes a raster image processor (RIP) and a printing system on the back end, which is optimized for the characteristics of the job, i.e. to print the job as fast as is possible.
The RIPing system needs to be able to deliver pages at least as fast as the rated engine speed of the output device. To this end, it must be possible to design a document that is largely made up of reusable page elements. Page elements can be text, graphics, images, or a combination thereof. Each personalized copy of a job can contain some unique information and some subset of these reusable page elements arranged by the document designer. Some of these elements are only used once, some are used on every copy of the document, and some are used only on select copies.
In a personalized job, page elements need only be RIPed once, then combined at the print engine. By only RIPing each element one time, unique documents can be delivered on-the-fly as quickly as possible.
Until now, personalized printing has been limited primarily to mass mailings such as utility and credit card bills, and specialized direct mail pieces. Applications are highly specialized for these specific uses and are costly to implement. Typically such applications have a high development cost, but generate very large volumes resulting in a low per-copy cost that tends to justify the initial high development cost.
For example, target marketing is generally considered to be less expensive and more effective than mass campaigns. Using demographic information to customize messages to the target audience produces significantly higher response rates. As time goes on, more and more information is collected from customer transactions. Companies use this information to customize their messages to their audience. They are then able to minimize their costs while realizing a greater return on investment.
FIG. 1 is a block schematic diagram that shows a general description of the data flow of a personalization front end system. The front end of a personalization system is composed of all of the applications necessary to build a personalized job that is delivered to the RIP. FIG. 1 depicts a simple data flow of the front end applications. It does not show the work flow which is described in more detail later. Such applications come in many shapes and sizes. Most personalization applications contain the above components in one form or another, but do not necessarily use them in the same ways. The majority of the front end applications are built by third party developers specializing in layout design, building graphics, and database design and access.
The following is a general description of the components of a front end system.
Database 14: Contains all of the information that are queried to generate the data set. It may contain demographics for target customers who receive customized bills or sales information. It could also contain information about a region of the country to drive specific versions of a sale catalog. For example, prices may differ by region, or depending on the current weather in the area, specific kinds of clothes could be chosen.
Page Elements 10: Page definition language describes a picture (e.g. graphics, or text) to be applied on a page.
A page element is defined in terms of (PDL) (e.g. PostScript, or HP PCL) or any other graphic format (e.g. TIFF or HTML).
Layout Description 12: A description of the layout (e.g. location, bounding box, orientation) of the elements on a page. A job might have layouts for several different pages. Each copy of the document could be made up of a different number of pages using, and possibly reusing, some or all of the layouts. The following convention is used to describe a page layout: EQU Page=(Application 1, Application 2, . . . Application);
where an Application applies a page element at a page location x,y for purposes of rendering the page element.
Merger 16: Builds the personalization specification file of the job. It uses the layout descriptions, page elements, and database queries to build a description of the final print job. The output of the Merger is a personalized job 18.
In the above example, the components of the process for building a personalized job are separate. Ideally, there are different people with different areas of expertise building each of the components of the job.
The page elements library is built by different artists, or potentially by scanning in different elements. There may be many sources of input for each page element.
The layout description is built by a graphic artist or report designer who creates the layout of the document. This person needs some minimal information about the page elements (such as size and rotation) but does not need to have direct access to the data to build the design. The artist also wants to take into account what database fields contain information to be used in the layout. Again, the specific data are not needed, just information about it. Tools are built to make this design process as easy as possible by providing a clean user interface for describing the representation of the page elements, including location, rotation, scale, and bounding box.
The database is most likely built by an information systems professional. The data can be directly generated from different sources of input such as credit card purchase information and past orders from mail catalogs.
FIG. 2 is a block schematic diagram that illustrates how the personalization components fit into a prior art RIPing system. In the prior art (such as the Supra product manufactured by Adobe Systems Inc.(see Personalized Printing, Adobe Systems Inc. (October 1996)); see, also D. Punater, R. Gaspar, V. Kubert, M. Duchesne, Printing Press and Method, U.S. Pat. No. 5,043,749 (Aug. 27, 1991) and D. Punater, R. Gaspar, V. Kubert, M. Duchesne, Printing Press and Method, U.S. Pat. No. 5,136,316 (Aug. 4, 1992), the focus is on RIPing jobs on a page parallel basis for fast throughput. The RIPed pages are then combined at the print engine. The prior art provides the ability to cache and reuse RIPed page elements. Multiple RIPs are used to process page elements in parallel. When this is combined with the reusability of those page elements, the result is improved performance for printing personalized jobs.
The merging is an automatic process generally done on a server. There should be no manual intervention necessary. All of the rules regulating database queries and what to do with nonstandard data should be defined before the merging takes place. The merger is tasked with building a personalized job. It queries the database to determine which information to place in each copy of the personalized document. It also specifies how many pages go in each copy, which template to use for each page, and which page elements to use in each of the fields in the layout description.
The output of the merging process is a personalized job. This job contains a description of the unique data for every copy of the document, as well as the page elements and layout descriptions. It also describes how to access each component.
The RIPing component of a prior art personalization system lies in between the front end system and the print engine. It receives as input from the front end. The RIP is also tightly integrated with the print engine which outputs the resulting personalized print run.
Personalized jobs 18 are delivered to the coordinator 20 inside Adobe's Supra product. The personalization module 22 is notified, and it then begins processing the file. The primary purpose of the personalization module is the management of page elements which are contained in the page element store 23. The personalization module controls their flow in and out of the system, their rasterization by the various RIPs 27a-27c, and their caching. As the variable data information comes in from the job source, the personalization module determines which page elements are required, whether they have already been rasterized, and which layout descriptions are required for the page. It also processes this information into a simplified form, which it then passes to the compositor 25 (described below). The compositor, in conjunction with an assembler 24, then uses this information to compose the rasterized page elements into the finished page which is delivered to the print engine 26 for printing.
The page store contains the variable information, page elements, and layout descriptions. Because the page elements and layout descriptions are only referenced in the variable data stream, they must be accessed and cached locally to optimize performance. The page element store, which in a non-personalization system contains only full-page raster data, contains rasterized page elements during a personalized job. The personalization module does not send elements to the RIPs twice.
The resource checker 21 communicates directly with the personalization module to verify that all the necessary page elements and templates are present. It does a preflight operation to ensure that the job prints successfully.
The compositor is responsible for combining the rasterized page elements into a final form for delivery to the print engine in real time. It knows the order in which to paint the page elements. Compositors have a full frame buffer of memory to use, several frame buffers, or maybe only enough memory for several bands. Some compositors composite multiple page elements at once, reading multiple channels simultaneously from the bitmap cache.
One disadvantage of such prior art techniques is the amount of memory and processing power required to store and merge the various elements of a job. Further, although there is some speed enhancement with such approaches, performance is still far short of that required for most commercial applications. It would be advantageous to provide a system in which jobs and applications require less compute power and less storage space, and in which RIPing and processing speed is increased.